Embodiments of the present invention relate generally to information distribution, and more particularly relate to systems and methods for disseminating security metadata.
In an enterprise deployment, distributed software applications typically rely on a centralized security service. These applications are known as “relying parties” because they “rely” on the security service to carry out various security functions. For example, a relying party may delegate responsibility for user authentication to a centralized Single Sign-On (“SSO”) server. In this scenario, the SSO server authenticates a user and passes the user's authenticated identity securely to the relying party. The relying party then accepts the authenticated identity from the SSO server and grants application access to the user. Since relying parties can take advantage of centralized security functions, they do not need to implement their own security modules. This simplifies application administration and deployment.
Implementing a centralized security service requires two-way trust to be established between relying parties and the security service. In other words, the relying parties must trust that all communications received from the security service are genuine, and vice versa. As known in the art, one way to establish this trust is through the use of security metadata (e.g., passwords, cryptographic keys, etc.). For example, a relying party may encrypt a user authentication request using a symmetric key known only to the relying party and the security service, and send the encrypted request to the security service. Since the relying party is the only other party that knows the key, the security service can trust that the request is genuine. Similarly, the security service may encrypt a response (e.g., authenticated user identity) using the symmetric key, and transmit the encrypted response to the relying party. Since the security service is the only other party that knows the key, the relying party can trust that the response is genuine.
In current implementations, security metadata can be distributed to relying parties manually (i.e., through human intervention). For example, an administrator of a relying party may contact an administrator of the security service via phone, email, physical mail, or the like and request security metadata. The administrator of the security service may then provide the security metadata in a disk, USB flash drive, email, or the like. In another (semi) manual approach, the security service may operate a self-service administration page for disseminating security metadata. The administrator of the relying party may login to the page and request security metadata, which is presented via a user interface to the administrator. The administrator may then manually record the presented metadata and insert it into the relying party system.
While these manual approaches are functional, they are also problematic for several reasons. First, they may be time-consuming. It may take a long time, for instance, for the administrator of the security service to respond to an email request. Second, these approaches are not particularly secure. Security metadata that is exchanged on a disk or USB drive is prone to theft or loss, and metadata that is sent via email is prone to being intercepted or viewed by unintended third parties. Finally, manual distribution is error-prone. Security metadata is often complex and “cryptic.” For instance, a 128-bit cryptographic key is represented as a string of 26 or more hexadecimal digits. As such, transferring this data manually can be difficult and result in transcription errors or other mistakes.
The dissemination of security metadata can be facilitated, to some extent, through public key infrastructure (PKI). In general, a PKI consists of client software, server software such as a certificate authority, hardware (e.g., smart cards) and operational procedures. PKI can be set up to provide for trusted third party vetting of, and vouching for, user identities. PKI arrangements enable computer users to be authenticated to each other, and to use the information in identity certificates (i.e., each other's public keys) to encrypt and decrypt messages traveling to and fro.
PKI is known for its complex deployment requirements and its usability issues are well documented. Some of the notable difficulties include certificate management, trust anchors management, and Information and Service Access control. Also, not all PKI operational procedures are fully automated in a typical deployment environment.
Thus, it is desirable to have a fully automated process for disseminating security metadata that overcomes the problems of manual distribution without incurring the complexities of a PKI deployment.